In industry, “two factor authentication” is a widely used term which describes a way of strongly authenticating a user trying to logon. There are three ways to identify a person: something they know such as a password; something they own such as a credit card; or something they are, such as a fingerprint. Two factor authentication simply means bringing two of these factors together and is interpreted largely as something you know (such as a password) and something you own (such as a token, phone or credit card).
Various attempts at using a mobile phone as a factor in authentication have been made by on-line banking portals and manufacturers of two factor authentication equipment, these all following a similar technique as follows:
The user logs on to a computer application by first entering their user identity (“UserID”) and a personal identification number (“PIN”), these being something they know. If these credentials are correct, a one-time passcode (typically six digits) is then sent from an authentication server as a text message to the user's mobile phone, this being something they own. The user enters this passcode, proving they possess the phone. After this passcode has been used it is locked, that is rendered unusable as a passcode for this user, to prevent any hackers or un-authorised person from trying to replay the already used passcode. For example, an indicator such as a “locked” flag might be set against the individual passcode at the authentication server.
Such a technique is relatively slow because the user has to enter three different pieces of information. Further, it has the serious drawback that it assumes that the passcode text message to the mobile phone can be sent in a quick and reliable fashion. It does not take into account the following three issues: text message delivery delays; signal dead spots; and conflict arising where a mobile device itself is used to connect to the Internet. Conflict can arise because a mobile device having a data connection established for authentication cannot receive text messages at the same time.
These problems arising in sending passcodes as the user logs on present serious reliability issues, particularly when scaled to higher numbers of users as the chances of incurring a text delivery delay or intermittent signal loss become higher.
In a known arrangement, a security code generator can instead be installed on the user equipment. This can generate a time-varying security code which the user can input to remote authentication apparatus in an authentication process. For example, originating with a seed record, the security code generator takes the current time and applies a hash function using a secret key to generate a multi-digit code which the user inputs. The creation of appropriate time-synchronised, one-time codes from a seed record is described in the “Request for Comments” RFC6238 published in May 2011 by the Internet Engineering Task Force (IETF) at: http://tools.ietf.org/html/rfc6238.
However, such techniques require co-ordination with the remote authentication apparatus. That co-ordination can be lost for various reasons, for example because times can drift on the user equipment or because the user adjusts the clock time.
It is known for the remote authentication apparatus to accommodate a degree of time slip between the user equipment and the authentication apparatus. Each code is usually relevant for a short period of time, for instance 30 or 60 seconds. The authentication apparatus might allow for a degree of time slip by accepting a code which would be generated by the user equipment just before or just after the correct time slot. However, this does not accommodate wide discrepancies. Discrepancies of several hours can arise for example because the user has travelled between time zones and then changed the clock on their user equipment.